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Abstract. The refinement calculus provides a methodology for transforming an 
abstract specification into a concrete implementation, by following a succession 
of refinement rules. These rules have been mechanized in theorem-provers, thus 
providing a formal and rigorous way to prove that a given program refines another 
one. In a previous work, we have extended this mechanization for object-oriented 
programs, where the memory is represented as a graph, and we have integrated 
our approach within the rCOS tool, a model-driven software development tool 
providing a refinement language. Hence, for any refinement step, the tool auto- 
matically generates the corresponding proof obligations and the user can manu- 
ally discharge them, using a provided library of refinement lemmas. In this work, 
we propose an approach to automate the search of possible refinement rules from 
a program to another, using the rewriting tool Maude. Each refinement rule in 
Maude is associated with the corresponding lemma in Isabelle, thus allowing the 
tool to automatically generate the Isabelle proof when a refinement rule can be 
automatically found. The user can add a new refinement rule by providing the 
corresponding Maude rule and Isabelle lemma. 
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1 Introduction 

Software verification is about demonstrating that an implementation (executable code) 
of the software meets its specification (formal description of the behavior) and several 
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techniques, roughly classified into two categories, are available in order to achieve this 
goal. The first category includes verification techniques taking both the specification 
and the implementation as inputs, and investigating whether the latter is an instan- 
tiation of the former. This investigation can be done for instance by running several 
instances of the implementation on specific inputs and monitoring whether the specifi- 
cation is respected during the execution (e.g. testing); by building an abstract model of 
the implementation and showing that the specification holds for any possible run (e.g. 
model-checking); by formally encoding both the specification and the implementation 
in a common language, using their respective semantics, and proving that the imple- 
mentation logically implies the specification (e.g. theorem-proving). 

The second category of verification techniques includes techniques where the im- 
plementation is generated from the specification, following a methodology guarantee- 
ing by construction that the implementation meets the specification. A typical approach 
is the program extraction from proofs |5|, which, using the Curry-Howard correspon- 
dence, where, from the proof of existence of some input satisfying a specification, a 
program implementing this specification can be automatically extracted. For instance, 
Coq's extraction mechanism of a program from a formal specification l34ll certifies 
that the program is correct with respect to this specification. Model-Driven Engineer- 
ing l27l considers a program as a model, which can be derived from another one using 
model transformations [38). Similarly, the refinement calculus [2 39 1 provides a formal 
language in which both abstract specifications and concrete implementations can be ex- 
pressed and mixed, and some formal refinement rules describing how to transform a 
program into another, more concrete one. 

In general, these techniques offer equivalent results: if an implementation is proved 
to meet a specification, then there exists a refinement chain from the specification to 
the implementation, and conversely, if there exists a chain of refinement from a spec- 
ification to an implementation, then it can be proven that this implementation satisfies 
this specification. Moreover, different techniques can be combined in order to exploit 
the strengths of each technique for a given context. For instance, a model-checker can 
be integrated into the Isabelle theorem-prover ifTHl , and test-cases can be automatically 
generated from an Isabelle specification Q. Similarly, model-checking can be used 
to verify refinement steps l22l . and the refinement calculus has been encoded into a 
theorem-prover PTll . 

In recent work [36 1, we have extended this encoding to object-oriented programs, 
by representing the memory of a state as a graph. Hence, a proof of refinement can 
be expressed as an Isabelle lemma, that needs to be proven by the user. Although we 
provide the user with a collection of lemmas to help her in this task, such a proof 
can still be challenging, in particular for users not familiar with Isabelle or theorem- 
proving in general. We address this challenge in this paper by providing a mechanism 
that automatically generates, when possible, the proof of the lemma in Isabelle. 

This work takes place in the context of the refinement for Component and Object 
Systems (rCOS) 1121131 . The rCOS language has a formal semantics based on an ex- 
tension of the Unifying Theories of Programming (UTP) [24| to include the concepts 
of components and objects, and an operational semantics based on graphs [26|. This 
language is supported by the rCOS tool l35l . which provides a UML-like multi-view 
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and multi-notational modeling and design platform. The rCOS tool already provides 
the user with a collection of complementary verification techniques, such as the auto- 
mated generation of robustness test cases 1311 . and the automated generation of CSP 
processes to verify the compatibility between the sequence diagram and the state dia- 
gram of a contract lfl4l . 

Contribution The main contribution of this paper is the extension of previous work 
on encoding the refinement of two rCOS programs as an Isabelle lemma [36|, with 
a module that performs an automatic search for a sequence of pre-defined refinement 
steps showing that the refinement is correct. In general, a given program can be refined 
in different ways, and it is not always possible to predict the sequence of refinement 
steps, or even to know if it exists. If the module can find a correct sequence, then it 
directly generates the Isabelle proof of refinement for the initial lemma. This module 
is written using the Maude rewriting tool |[T6l . such that refinement rules are defined 
as rewriting rules, and each rewriting rule is associated with the corresponding Isabelle 
refinement lemma. 

The main focus of this work is to present the architecture of the framework, thus 
describing how different environments (rCOS, Isabelle, Maude) interact together rather 
than presenting an encoding of a refinement calculus. Hence, we build upon the previous 
encoding of the refinement calculus [47 29 20], and only redefine what is necessary for 
our integration with Maude. 



Organization The main novelty of this paper is the automatic generation of Isabelle 
proofs of refinement of rCOS programs using Maude. In order to present and explain 
this automatic generation, we first briefly introduce the rCOS language together with 
some simple illustrating examples in Section [2] we recall the previous mechanization 
of the refinement calculus in Section[3] and we present our graph-based memory repre- 
sentation of object-oriented programs together with the corresponding extension of the 
refinement calculus in Section|4]and Section|5] respectively. 

We then present the Maude module in Section|6] and provide an example of gener- 
ated proof in Section|7] We discuss the well-known aliasing problem and show how to 
consider it in our approach in Section [8] Finally, we present related work in Section [9] 



and conclude and present future work in Section 10 



2 rCOS 

The rCOS method consists of two parts: a component/object-oriented language with 
formal semantics, and a modeling tool, enforcing a use-case based methodology for 
software development, providing tool support and static analysis. We use only a subset 
of the language in the examples presented in this paper, however we give here a brief 
description of the whole language, and we refer to [ 13] for further details. 

The rCOS language is an extension of UTP 1241 . to include object-oriented and 
component features, and as such, the semantics of a program in any programming lan- 
guage can be defined as a predicate, called a design. Roughly speaking, a design can be 
a traditional imperative statement, such as: an assignment p := e, where p is a path to a 
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memory location and e is an expression; a conditional statement d\ < b t> da, where d\ 
and <^2 are designs and b is a boolean expression; a sequence di;d2> where d t and ^2 are 
designs; a loop do b d, where d is a design and b is a boolean expression; a local variable 
declaration and un-declaration var T x = e ; end x, where T is a type; an atomic design 
such as SKIP ; CHAOS. 

A new object of type C is created and attached to the path p through the command 
C.new(p). A method invocation has the form e.m(i; o), where m is a method, i stands 
for the input parameters and o for the output parameters. If there is no output parameter, 
we can write directly e. m(i). 

A design can also denote a more abstract specification, such as a pre/postcondi- 
tion |2 39| [pre(x) h R(x,x')], meaning that if the program executes from a state 
where the initial value x satisfies pre(x), the program will terminate in a state where 
the final value x' satisfies the relation R(x,x') with the initial value x. Similarly, non- 
deterministic choice is defined as d\ Udi, where d\ and di are designs. 

The rCOS language includes the notion of components, which provide or require 
contracts. A contract includes an interface (a set of field and method declarations), the 
specification of each method and a protocol stating the allowed sequences of method 
calls (for instance, for a buffer, the method put must be called before the method get). 
A component provides a contract through a class, where each method has to be de- 
fined using a design. Note that the design of a method can either be abstract (pre/post- 
conditions, non-deterministic choice, etc), concrete (standard imperative and object- 
oriented features), or both at the same time, but only concrete programs can be gener- 
ated to Java. For instance, all the following examples are correct rCOS programs. 

class A { class B2 { 

int x ; A a ; 

public m(int v) { public foo() { 

x := v } [true h a.x'=l] ; 

} a.x:=a.x+l} 

} 

class B3 { 

class Bi { A a ; 

A a ; public foo() { 

public foo() { a.m(l) ; 

[true ha.x'=2 V a.x'=3]} a.x := a.x+1} 

} } 

The method B\ ::foo is abstract and non-deterministic: it just specifies, under the true 
precondition, that the value of the field x of the field a should be either equal to 2 or to 3. 
The method i?2"f°° mixes abstract pre/postconditions with a concrete assignment while 
B3::foo is completely concrete and could be directly translated to Java. In this example, 
we can see that B^ifoo is refined by B2-.foo, which is refined by B^::foo. We detail in the 
following section the mechanization of the notion of refinement. 



3 Mechanized Refinement 



The refinement calculus [2 39 1 is a program construction method, where a non-deterministic 
specification is incrementally refined to deterministic code, using pre-defined rules. 



5 



This calculus has been fully encoded into the theorem prover HOL, an ancestor of 
Isabelle, in [47 20 1 and then extended, in particular in |29l , which introduces, among 
others, procedures and recursive functions. The encoding follows the weakest precon- 
dition approach: for any design d and any predicate q over states, the function wp(d,q) 
stands for the weakest precondition that should be true on states before executing d such 
that q holds after executing d. Therefore, a design is usually considered as a predicate 
transformer, since it takes a predicate (q) as input and returns another predicate (the 
weakest precondition of q). We recall here the definitions of assignment and refinement 
from [47 1 . We use State to represent the type of a program state, which is defined as 
a tuple of values in [47], and represented as a graph in l36ll and in this document. We 
introduce first the type of predicates over states and the type of predicate transformers. 

types State pred = State => bool 

State predT = State pred => State pred 

The assign predicate transformer takes a function e, which takes a state and returns 
the state where the corresponding assignment is done. The weakest precondition of a 
predicate q is calculated by checking q on a state where the assignment has been done. 

definition assign :: (State => State) =S> (State predT) 
where 

assign e q = Xu. q (e u) 

A design cl is refined by a design c2 if, and only if, the weakest precondition of cl 
implies the one of c2 for any state. 

definition implies :: (State pred) => (State pred) => bool 
where 

implies p q = V u. (p u) 4 (q u) 

definition ref : : ( State predT) => ( State predT) => bool 
where 

cl ref c2 = V q. (implies (cl q) (c2 q)) 

Although the previous definitions do not directly depend on the structure of the 
state, this structure is defined as a tuple in [47], where each element of the tuple is the 
value of a variable of the program. For instance, if a program has two variables x and 
y, set respectively to 1 and 3, the state of such a program is the pair (1,3). The names 
of the variables are therefore lost in the translation, and any operation concerning x has 
to be translated as an operation concerning the first element of the pair. Dealing with 
local variables and method calls thus implies to extend and narrow the state, respec- 
tively. Moreover, this approach does not directly handle references and therefore such a 
representation for states cannot be applied for object-oriented programs. The usual way 
to tackle this issue is to represent a state as a record or as a function from pointers to 
values 03141110 441. A recent approach uses graphs instead ll26l . and we present it in 
the next section. 
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4 Graph Representation 

In l26l . the state of a program is represented as a directed labeled graph. We only give 
here a simple description of such a graph and its implementation in Isabelle/HOL, more 
details can be found in B26I361 . 



4.1 State Graph 

Intuitively, the state graph represents the abstract structure of the memory, such that an 
rCOS navigation path is represented by a path in the state graph. Hence, a vertex can be 
either a root, a node or a leaf. A root represents a scope, and local variables start from a 
root. A graph thus has a list of roots, one for each scope, and the root at the head of the 
list stands for the current scope. For the sake of readability, we connect the roots using 



edges labeled by $ (the current root having no incoming edge). For instance, Figure 1(a) 
illustrates the state of the graph after executing the statement v.a . b.x :=l;var int v=2. 
The creation of the new variable v leads to the creation of a new scope r%, from which 
this variable starts. When the scope exits, the node r2 is removed, and so the newly 
created variable v is no longer accessible; the previous root r\ becomes current scope 
again. 

A non-root vertex in a state graph represents either an object or a primitive datum, 
called node and leaf, respectively. A node is labeled by the runtime type of the object, 
while a leaf is labeled by the primitive value. An outgoing edge from a node is labeled 
by a field name of the source object and refers to the target node or leaf representing 
the value of this field. There is no outgoing edge from a leaf. Note that, as illustrated on 



Figure 1(b) objects can be recursive. 




(a) State af- (b) Recursive ob- 

ter execution of ject 
v.a. b.x :=1; var int v=2 



Fig. 1. Examples of state graphs 



We implement the state graph in Isabelle by first introducing the datatype vertex, 
which is the union of the base types root, node and leaf. We also consider a special 
vertex, _L, which stands for the undefined vertex. 

datatype vertex = N node | R root | L leaf | ± 
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A state graph is defined as a list of roots, and a function taking a vertex vi and a label 
/ (i.e. a string for representing variable or field), and returns the vertex V2 if (vi,Z, V2) is 
an edge of the graph, or _L otherwise. We write G for the type of graphs. 

types 

edgefun = vertex => label => vertex 
G = edgefun * root list 

In order to ensure that there is no edge starting with the undefined vertex _L, we 
introduce the following propert)]^] 

definition isGoodFunction:: G => bool 
where 

isGoodFunction g = V x. (getEdgeFun g) J_x = J_ 

where getEdgeFun g is used to get the first component of g. 

Moreover, we must ensure that the list of roots is consistent with the edge function, 
and so we say that a graph is well-formed, which we denote with the predicate wfGraph, 
if, and only if, in addition to satisfy isGoodFunction, each root is unique in the list of 
roots and is not the target of an edge, and there exists at least one outgoing edge for each 
root. We could similarly add the property that there are no outgoing edges from leaves, 
however, we do not need it in the current state of the development and therefore we 
chose not to add it. In general, it must be pointed out that we assume that the programs 
and memory states encoded in Isabelle are generated from correct rCOS programs. 
In other words, we do not expect the users to directly write programs in Isabelle, but 
instead to write them using the rCOS tool, which features a type-checker, and so can 
prevent by construction the generation of some not well-formed states, for instance one 
with an outgoing edge from a leaf. Hence, we only specify the state properties we need 
in order to prove the desired lemmas. 



4.2 Graph Operations 

This section briefly describes some basic graph operations that are needed for the en- 
coding of the refinement calculus. Due to space limitation, we do not present here the 
implementation of these functions, more detailed explanations can be found in [36 1, and 
the complete list is available onlin^] 

We first introduce the type path as a list of labels, which, for implementation opti- 
mization reasons, is reversed: the path a. b.x is represented by the list ["x" , "b" , "a "] 
The vertex corresponding to a path p in a graph g is given by getVertexPath p g. 

The function swingPath swings the last edge of a path in the graph to point to a new 
vertex. In other words, it sets a new value to a path in a state graph, and therefore, can be 
used for implementing assignments in rCOS. This function has been proved to preserve 
the well-formedness, i.e. for any graph g, any path p and any non-root vertex n, if g is 
well-formed then (swingPath p n g) is also well-formed. 

5 Note that we could equivalently constrain the range and domain of the function getEdgeFun, 
however doing so tends to make the usage of this function more complex, since Isabelle does 
not provide a native subtyping mechanism. 

6 http: / /www. doc. ic.ac.uk/~agriesma/mircos/graph_utl. thy 



8 



Intuitively, we would like to express the fact that after swinging a path to new 
vertex, this path actually points to this vertex. In practice, this is not true for every 
path. For instance, consider an infinite list such that x.next points to x. If we execute 
x. next . next := y, where y is another list, this is equivalent to executing x. next := y, and 
after the assignment, x. next. next points to y . next, which can be different from y. This 
kind of situation happens when more than one prefixes of a path are aliasing with the 
owner of the path {i.e. not the vertex pointed by the path, but the one before). Clearly, 
when dealing with such paths, some refinement rules do not hold any longer, for in- 
stance that [h p' = e] is refined by p := e (the corresponding refinement lemma is 



given in Section 6. 1 



Hence, we introduce the predicate isGoodPath, such that given a path p, isGoodPath p 
is true if, and only if, there is only one prefix of p that points to the owner of p. 
For instance, in the state graph in Fig. 1(b) the paths v. a, v.a.b.c and v.a.b.x satisfy 
isGoodPath, while the paths v.a.b.c. a and v. a . b.c.a.b.x do not. We can observe that the 
path v.a, which satisfies isGoodPath, points to the same object as v.a.b.c. a, and we can 
safely replace v.a.b.c. a by v.a, and obtain an equivalent program. By extending this 
observation to all paths, we can assume that any path that does not satisfy isGoodPath 
can be replaced by a path that does, following the idea that any cycle can be removed 
from a path in a graph. We assume here that this substitution is done at the rCOS level, 
and that any path considered in Isabelle satisfies the predicate isGoodPath. 

Furthermore, a path p is said to be well-formed with respect to g, denoted by 
wfPath p g, if, and only if, the vertex of p exists in g, and p satisfies isGoodPath. Note 
that since the paths are generated from a correct rCOS program, and since rCOS has 
a type-checker, it follows that the paths are well-typed, and therefore that the vertex 
pointed by a path always exists in a graph. 

One of the most important theorems of our theory is swingPathChangeVertex: given 
a well-formed graph, swinging a well-formed path to a new vertex makes this path point 
to this vertex in the resulting graph. 

The function Vars combines the operations of creating a root vertex and adding 
edges, and therefore implements local variable declaration. In a similar way, the func- 
tion removeSnode removes the top root from the root list, and in consequence all edges 
outgoing from the root. It implements local variable un-declaration. Finally, the func- 
tion addObject creates a new node vertex (object) in a graph. These functions are proved 
to preserve the graph well-formedness. 



5 Refinement of rCOS Designs 

The graph-based representation of the memory presented in the previous section allows 
us to extend the mechanization of the refinement calculus presented in Section [3] to 
deal with object-orientation. Since we only consider well-formed graphs and paths, 
we integrate these conditions into the weakest precondition of each command. The 
complete definition of the refinement calculus for all constructs is available onlinaj 



http:/ /www. doc. ic.ac.uk/~agriesma/mircos/rcos. thy 
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5.1 Primitive Designs 

Pre/post-condition The definition of the non-deterministic assignment, which stands 
for a predicate between the next graph and the past one, needs to include the well- 
formedness checks. 

definition nondass :: ( G => G pred) => path list => ( G pred) => ( G pred) 
where 

nondass P 1 q = (Av. (wfGraph v) & (wfPathl 1 v) & (V vl. P V vl => q vl)) 

where wfPathl I v is true if, and only if, every path in I satisfies wfPath. This list of 
paths corresponds to all the paths appearing in the postcondition. A pre/postcondition 
is then an assertion followed by a non-deterministic assignment. 

definition pp :: ( G pred) =>(C=>G pred) path list ( G predT) 
where 

pp p r 1 = assert p ; nondass r 1 

where assert is the standard definition for the assertion. For instance, the design of the 
method Bi::foo given in Section [2] and defined by [ true h a.x'=2Va.x'=3 ] is trans- 
lated into the statement: 

pp (true) (A g. Agl. ((getNVal this.a.xgl) = 2 | (getNVal this.a.xgl) = 3)) [this. cue] 

where getNVal is the function returning the value (as a nat) of the path in the given graph 
and where, for the sake of readability, we abbreviate the path [" x " , " a " , " this "] as 
this.a.x. 

Assignment The definition of the assignment is changed as follows. 

definition assign :: path => exp =>■ ( G pred) =>■ ( G pred) 
where 

assign p e q = Au. wfGraph u & wfPath p u 

& wfExp e u & q (swingPath p (getNodeExp e u) u) 

where the path p is assigned to the expression e, which is required to be well-formed. 
The function getNodeExp returns the value of an expression, which is obtained using 
getVertexPath when the expression to be evaluated is a path, otherwise itself when it is 
a constant value. For instance, the assignment a .x := a .x+1 of the method B2"f°° given 
in Section|2]is translated as: 

assign this.a.x (Plus (Path this.a.x) (Val (Zint 1))) 

Local declaration and un-declaration The commands begin and end declare/initialize 
new local variables and terminate them, respectively. 

definition begin :: labelExpF => ( G pred) => ( G pred) 
where 

begin f q = Au. wfGraph u & wflabelExpF f u & q (Vars f u) 

definition end :: ( G pred) => ( G pred) 
where 

end q = Au. wfGraph u & q (removeSnode u) 
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where f is a well-formed function of type labelExpF (i.e. label => exp, mapping vari- 
ables to their initial expressions), which means that for each local variable, it is initial- 
ized by a well-formed expression in f. 

The command locdec defines the block for local declaration and un-declaration, 
where f is the same as above and c is the body of the block. 

definition locdec :: labelExpF => ( G predT) => ( G predT) 
where 

locdec f c = begin f ; c ; end 

Method invocation The command method implements a method invocation with the 
help of the command locdec. 

definition method :: (label * exp) list => ( G predT) => ( G predT) 
where 

method 1 c = locdec (getLabelExpF 1) c 

where I is of type ( label * exp) list , each pair consisting of a formal parameter and 
its actual value, and c is the method body followed by the assignment from the formal 
return parameter to the actual return parameter. In the method command, the function 
getLabelExpF translates a list of pairs of type label * exp to the corresponding mapping 
of type labelExpF (i.e. label => exp). For instance, the method call a . m(l) of the method 
53::foo of Section[2]is translated as: 

method [(this, Path this.a), (v, Val (Zint 1))] ; assign this.x Path v 

When the method is called, the variable this is substituted by this.a (the caller), and v 
by 1 . Note that with this approach, recursive method calls are not directly handled, and 
require the definition of a fix-point, which we do not consider here. 

5.2 Composite Designs 

With the predicate transformer semantics, the definitions of the composite designs, like 
the sequential composition, the loop or the conditional statement, do not depend on the 
representation of the memory state. Hence, we can directly re-use the definitions and 
theorems from [47 1. For instance, the sequential composition c; d is refined by e; f if c 
is refined by e and d is refined by f and c is monotonic, and in fact, we have proved that 
all basic commands (i.e. nondass, pp, assign, begin and end) are monotonic, and the com- 
pound constructs locdec, method, cond, do, seq preserve monotonicity with respect to 
their subcomponents. Moreover, the other constructs such as the conditional cond and 
the loop do preserve refinement with respect to their subcomponents. By applying these 
theorems, we can refine a program by repeatedly refining its subcomponents, and then 
prove that the new generated program is a refinement of the old one. 

5.3 Tool Refinement 

Refining a model is, by definition, a dynamic process: a new model is generated from 
a previous one, by applying some refinement rules. The main challenge is then to be 
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able to consider both models at the same time, in order to generate the corresponding 
proof obligations. When the refinement concerns only method bodies, the rCOS tool 
provides a simple way to define a refinement operation. Firstly, a class is created, and 
stereotyped with a specific kind of refinement, for instance refining automatically every 
[true h x'=e] by x := e. The most general refinement is the manual refinement, where 
the user provides an operation, its old design (mainly for sanity checks), and the refining 
design. In a second step, the user can, at any time, apply such a refinement by right- 
clicking on the corresponding class and selecting the "refine" operation, and the tool 
then transforms the model accordingly. 

For instance, the user can indicate can create a new class to specify that the design 
of £i::foo is refined by the design of i?3::foo, given in Section [2] i.e. the user wants to 
prove that the design [ true h a .x'=2Va.x'=3 ] is refined by a.m(l) ; a .x := a .x + 1. 
In this case, the rCOS tool generates the following Isabelle lemma: 

lemma bl_foo_ref_b3_foo : 
"pp ( true ) (X g. X gl . ((getNVal this.a.x gl) = 2 | (getNVal this.a.x gl) = 3)) [this.a.x] 
ref 

((method [(" this", Path this.a), ("v", Val (Zint 1))] (assign this.x (Path ["v"]))) ; 
assign this.a.x (Plus (Path this.a.x) (Val (Zint 1))))" 

Note that at this stage, the rCOS tool only generates the statement of the lemma, and 
not the proof. The user can either try to prove it manually, or to use our Maude module, 
presented in the following section. 

6 Automatic Proof Generation 

Intuitively, we define for each refinement step a rewriting rule and an Isabelle lemma, 
such that when the rewriting rule is applied, the corresponding refinement step can be 
directly proven. Hence, the global architecture of our system, illustrated in Fig. [2] can be 
described as follows: given two rCOS programs p\ and p2, the rCOS tool generates both 
the Isabelle statement lemma p\ ref pi , as described in Section |5T3| and the Maude term 
(id {p\ } ~> {pi} status : s), that we describe in the following. When the Maude module 
can find a rewriting sequence, then it generates the Isabelle proof for the lemma. 

We first introduce some examples of refinement lemmas we provide, then we briefly 
introduce Maude lfl6l and present the rewriting rules corresponding to the refinement 
rules, and finally show how to extract an Isabelle proof. A detailed example is given in 
Section|7] 

6.1 Refinement Lemmas 

In addition to the theorems introduced in B71 . we provide lemmas corresponding to 
refinement steps. For the sake of simplicity, we only focus here on lemmas concerning 
integers, however equivalent lemmas can be defined for other primitive types. 

For instance, the lemma stating that for any path p and any integer n, the statement 
[true h p'=n] is refined by the assignment p := n is definedjas: 




8 Due to space limitation, we do not include in this document the proofs of the lemmas, which 
can be found at http://www.doc.ic.ac.uk/~agriesma/mircos/rcos_lib.thy 
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Fig. 2. Workflow 



lemma reLpp .assign : 
"pp (true) (X g- A gl .((getNVal p gl) = n)) [p] 
ref 

(assign p (Val (Zint n)))" 

Another example is the Expert Pattern, which is an essential rule for object-oriented 
functionality decomposition by delegating responsibilities through method calls to the 
objects, called the experts, that have the information to carry out the responsibilities. 
For instance, defining a setter for a field is a special case of the Expert Pattern, and 
therefore a refinement. As a special instance of this pattern, we have defined the lemma 
EPIsRefTwo, which states that the statement p. a := n is refined by the method p.m(n) 
where m (T v) {this .a := v} is a method of p, for any primitive type T and parameter 
v. 

lemma EPIsRefTwo : 

"p/ [] =► b + c => 
(assign (p. a) (Val n) 
ref 

(method [(b, Path p), (c, Val n)] (assign (b.a) (Path [c ]))))" 

This lemma only considers attribute accesses (if p is empty, then p. a represents a local 
variable and Expert Pattern is not necessary), and that b and c are the formal parameters 
of the method, and therefore must be different. 

Finally, the lemma assign.end states that given a path p and two integers m and n, 
the statement p : = m is refined by p := n; p : = p + (m — n). 

lemma assign_end : 
"(assign p (Val (Zint m))) ref 
(assign p (Val (Zint n)) ; (assign p (Plus (Path p) (Val (Zint (m-n ))))))" 



6.2 Maude 



Maude is a rewrite tool that allows the specification of equations and rewrite rules 
which have a simple rewriting semantics in which instances of the left hand side are 
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replaced by corresponding instances of the right hand side. The set of equations is de- 
signed to be confluent and terminating. This means that starting from a term, every 
possible sequence of applications of equations leads to a canonical form made from 
ground terms, which also give the means to define the type system of the implemented 
logic. Application of rewriting rules, on the other hand, needs neither be confluent nor 
terminating, and allows to express the evolution of the system. Eligible rules are se- 
lected by pattern matching: while equations have a deterministic result for any enabling 
term and are executed immediately by the Maude engine, the order of execution of 
rewrite rules may lead to different results. Thus, the application of rewrite rules spans 
a state space that can be explored by choosing among enabled rewrite rules. Intuitively, 
we thus define a state as a set of proof obligations that is known at any point in the 
execution and will use rewrite rules to generate new proof obligations and search for 
the proof, while the equations provide us with a canonical representation of equivalent 
terms, and discharge simple proof obligations. 

6.3 Rewriting Rules 

In order to search for a sequence of steps to form a proof of refinement, we use Maude 
to systematically perform syntactical rewriting starting with an initial proof obligation 
that represents the refinement of a specification by an implementation. In the context of 
Maude, we write a proof obligation as (id, {p\} ~> {pi}, status :sfrom :/), where id is 
an identifier of the proof-obligation, {p\} ~> {p2\ stands for the refinement step of p\ 
to p2, f refers to further proof-obligations that need to be fulfilled such that the rule can 
be discharged, and s is the status of the proof-obligation. The status can either indicate 
that it is still undetermined how to discharge the proof-obligation, (marked as todo), or 
it gives a lemma with which it should be discharged in Isabelle. 

We distinguish between two kinds of rewrite actions: 1) setting up new proof obli- 
gations according to the syntax of the present obligations and 2) discharging proof obli- 
gations according to the the basic refinement steps proved by Isabelle as described in 
the previous sections. These kinds of rules often come in pairs where the former type 
of rules generates the proof obligations that are required by the latter, as shown below 
for ref — sequential. Only when all dependencies are proven, their id is stored in the from 
field and the proof obligation is discharged. Note that some of those steps are imple- 
mented as equations for performance reasons. This can be done if the application of 
the rule is definitely required and the outcome is deterministic. E.g., the refinement be- 
tween two identical terms is immediately discharged by the ref — reflexive rule. Other 
rules introduce new proof-obligations on a speculative basis. Such rules may or may 
not be required in the process of finding a proof and therefore, according to the defini- 
tions of equations and rewrite rules given above, are implemented as rewrite rules. For 
simplicity of presentation, we give here all of the steps in form of rewrite rules. 

In the following, we present some selected rules for generation and discharging of 
proof obligations as rewrite rule^] The syntax for expressions and statements in Maude 
is very similar to the syntax of the Isabelle lemmas; in fact, the communication between 

9 The complete definition in maude rewriting logic can be found at 
http : //www . doc . ic . ac .uk/~agriesma/mircos/rcos .maude 
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the tools can be done by a simple maude export expression and a script that replaces 
some reserved key symbols, in the remainder of the section we stick to a slightly sim- 
plified presentation of the rules; in particular, we omit the environment taking track of 
details like number of open obligations and similar. We use SI .. S4 to denote statements, 
El, E2 for expressions and X for variables. The presented rules (rl) have the following 
structure: 

rl [name] po\, - ■■ ,po^ => po^+x, ■ ■ ■ ,po n . 

where name identifies the rule, and po[ are proof-obligations. At least one of po\ . . .po^ 
is undischarged, marked by a status equal to todo. Conditional rewrite rules (crl) have 
an additional " if El" clause that needs to evaluate to true for the rule to be enabled. For 
instance, the rule ref— reflexive can be defined as: 

rl [ ref — reflexive ] : 
( id { X } ~> { X } status :todo ) => 
( id { X } ~> { X } status : ref- reflexive ) . 

This rule can be read as follows: if we need to discharge the proof-obligation that the 
program X refines the program X, then we can directly do so by using the Isabelle lemma 
ref — reflexive. New proof obligations are introduced by pattern matching of present 
proof obligations. For instance, the refinement rule ref-sequential-genl matches for 
sequences of statements and introduces a new proof obligation (note that id 2 is a fresh 
identifier). 

crl [ref — sequential— gen 1] : 

( idi { SI ; S2 } ~>{ S3 ; S4 } status : todo ) => 

( id\ { SI ; S2 } ~>{ S3 ; S4 } status : todo ) , 

( id 2 { SI } ~>{ S3 } status : todo ) 

if new(Sl, S3 ) . 

This rule represents the fact that in order for the left hand side (LHS) to be refined by 
the right hand side (RHS), the first statement on the LHS, SI, needs to be refined by 
the first statement on the RHS, S3. (An analogous rule exists for the second statement.) 
The rule is conditional and only creates a new proof obligation if {Si} ~> {53} is not 
present yet. Similar rules exist for other constructs and can also match multiple present 
proof obligations to, e.g., create a missing part for the lemma of transitivity. 

The corresponding discharge rule for refinement of sequences makes sure that the 
proof that SI ; S2 is refined by S3 ; S4 is only discharged if, and only if, we have dis- 
charged proof-obligations id.2, stating that SI is refined by S3, and idi, stating that S2 is 
refined by S4. This is recorded by setting the status: to the Isabelle lemma ref-sequential, 
with its arguments idi and idi stored in the from: field: 

crl [ref — sequential] : 
(id! { S1;S2 } ~>{ S3;S4 } status: todo ) 
(id 2 { SI } ~>{ S3 } status : statl ) , 

(idi { S2 } ~>{ S4 } status : stat2 ) , 



=> 



(idi { S1;S2 } ~>{ S3;S4 } status: ref 
(id 2 { SI } ~>{ S3 } status : 

(id 3 { S2 } ~>{ S4 } status : 



- sequential 
statl ) , 
stat2 ) 



from: id 2 idi) 
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if statl != todo and stat2 != todo . 

The provided rules may not always be sufficient to fully discharge all proof obli- 
gations. E.g., the rule ref — strengthen refines a pre/postcondition by replacing the post- 
condition by another one that logically implies it as follows: 

rl [ref —strengthen] : 

(id {[ |- E2 ]} ~>{[ |- El ]} status : todo ) => 

(id {[ j — E2 ]} -~>{[ |— El ]} status : ref —strengthen from: id2), 

(id2 prove (El => E2) status : sorry ) . 

We use the Isabelle keyword sorry to denote that the proof-obligation cannot be dis- 
charged in Maude, and therefore has to be done in Isabelle, where this keyword allows 
one not to provide the proof of a lemma. This approach makes it possible to consider 
the postcondition strengthening refinement rule regardless of the postcondition itself, 
by delegating the burden of the proof to Isabelle. However, some instances of this rule 
are quite simple, and can be done directly in Maude. For instance, the rule ref — d isj — left 
chooses a member of the disjunction in a postcondition. 

rl [ref— disj] : 

(id {[ - El \/E2 ]} ~>{[ |- El ]} status : todo ) => 
(id{[ j— El \/E2]} ~>{[|-E1]} status: ref -disj -left) . 

A major strength of this approach is its extensibility: new refinement rules can be 
easily added, simply by adding the corresponding rewriting rules in the Maude file, and 
the corresponding Isabelle lemmas in the Isabelle file, without any required modifica- 
tion to existing code. Hence, sets of rules can be dynamically loaded and unloaded, to 
adapt to different contexts. 



7 Example 

We consider the lemma bl_foo_ref_b3_foo from Section [53] which expresses that the 



design of the method Z^-foo is refined by the design of £3::foo, given in Section|2] The 
following maude term is generated by the Maude module: 

{[ |- 2 = a.x ' V 3 = a.x ']} ~> 

{method[([" this "] , ["a"]) , ["v"] ,1 ](this.x := ["v"]) ; a.x := 1 + a.x} status: todo]) 

where, here again, we abbreviate paths. Maude applies enabled rules until a proof for the 
refinement is found. The sequence of rewrite rules applied to generate the proof below 
is shown in Table [T] We see the rules that correspond to actual lemmas in the Isabelle 
proof (e.g., ref — transitive) interleaved with rewrite rules that tentatively generate new 
proof obligations for the search (rules containing gen). By default we select the shortest 
proof. Note however, that this is not a unique solution — an alternative, slightly longer 
sequence of steps is shown in Table [2] We see that, additionally to the order in which 
new obligation are created, we also may have additional generation- and discharging 
rules (e.g., the alternative proof contains four ref — transitive lemmas). Searching for 
the shortest proof is not trivial and can be abandoned in favor of a longer path if a 
predefined time limit is exceeded. The found proof for Table[T]is given in the following 
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ref-mcall-gen 

ref-sequential-gen 1 

ref-sequential-gen2 

is-ident 

ref-mcall 

ref-sequential 

ref-transitive-gen-left 

ref-add-gen 

ref-add 

ref-transitive-gen-left 

ref-pp-assign 

ref-disj-left 

ref-transitive-gen-right 

ref-pp-assign 

ref-transitive 

ref-transitive 

ref-transitive 



Table 1. minimal rewrite steps 



ref-mcall-gen 

ref-sequential-gen2 

ref-sequential-gen 1 

is-ident 

ref-mcall 

ref-sequential 

ref-transitive-gen-left 

ref-add-gen 

ref-add 

ref-transitive-gen-left 

ref-pp-assign 

ref-disj-left 

ref-transitive-gen-right 

ref-transitive-gen-right 

ref-pp-assign 

ref-transitive 

ref-transitive 

ref-transitive 

ref-transitive 

Table 2. alternative sequence 



(for the clarity of the presentation, we have manually added the definition of the ?X 
terms, the proof being equivalent without them, but much harder to read): 

proof 

let ?A = "(pp (X g. True) (X g. X gl .((getNVal this.a.x gl) = 2 )) [this.a.x] )" 

let ?B = "( assign this.a.x (Val (Zint 2)))" 

have f9: "?A ref ?B" by (simp add: ref_pp_assign ) 

let ?C="pp (Ag. True) (X g. X gl .((getNVal this.a.x gl) = 2 

(getNVal this.a.x gl) = 3)) [this.a.x ]" 
havef8: "?C ref ?A" by (simp add: ref_disj_left ) 

fromf8 f9 havef7: "?C ref ?B" by (simp add: refjransitive [of ?C ?A ?B]) 

let ?D = "( assign this.a.x (Val (Zint 1))) ; (assign this.a.x (Plus (Path this.a.x) (Val (Zint 1))))" 

have f6: "?B ref ?D" 

by ( insert assign_end [of this.a.x 1 1], simp ) 
from f7 f6 have f5 : "?C ref ?D" by (simp add: ref.transitive [of ?C ?B ?D]) 
let ?E = "assign this.a.x (Val (Zint 1))" 
have f4: "monotonic ?E" by (simp add:assign_monotonic) 
let ?F = "(method [(" this " , (Path this. a)), ("v", (Val (Zint 1)))] 

(assign this.x (Path ["v"])))" 
let ?G = "assign this.a.x (Plus (Path this.a.x) (Val (Zint 1)))" 
have f3 : "?G ref ?G" by (simp add: ref_reflexive ) 
havef2: "?E ref ?F" by (simp add:EPIsRefTwo) 
from f2 f3 f4 have fl : "?D ref ?F ; ?G" by (simp add: seq_ref ) 
fromf5 fl have fO: "?C ref ?F ; ?G" 

by (simp add: ref-transitive [of ?C ?D "?F ; ?G"]) 
from fO show ? thesis by simp 
qed 
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This proof is correct, and can be instantly verified by Isabelle. Note that although it 
is quite long for a simple lemma, each step is atomic, since only one lemma is used for 
each step. In practice, it is possible to come up with a shorter, but equivalent proof of 
this lemma, by manually "inlining" the facts: every time that a fact /; is used to prove a 
fact fj, we try to prove directly /,• by adding the tactics used for fi. If it succeeds, then 
// can be removed. However, in general, it is not trivial to find out which facts can be 
removed. 

8 Aliasing 

In an object-oriented program, an accessible object may be referred to by multiple nav- 
igation paths, which are aliasing to each other. Because an object can be modified via 
any alias, the behavior of object-oriented programs is hard to specify and verify. Re- 
cently, object aliasing has been extensively studied, and many methods and techniques 
for aliasing analysis and control have been proposed, in particular shape analysis ll43ll . 
separation logic [42], and ownership types [ 15|. By applying these different techniques, 
it can be checked whether two expressions in a program execution may become aliased, 
and furthermore, provided with the known alias relations, what properties a program 
will satisfy. 

Our graph-based implementation of program states makes object aliasing easy to 
interpret: two paths are aliasing in a graph if, and only if, they refer to the same vertex 
in the given state graph. We therefore introduce the predicate alias, and we can easily 
prove the following lemma^ 




lemma aliasPreservesAssertAssign : 

" implies q ( alias pi p2) =>■ implies q (wfPath (p2.a)) => 
assert q ; assign (pi. a) x ref (assert q; assign (p2.a) x)" 

This lemma states that if pi and p2 are aliases, then pi. a := x is refined by p2.a := x. 
The hypothesis with (wfPath (p2.a)) can be in practice automatically discharged, since 
the generation from rCOS to Isabelle ensures to consider only well-formed paths. Note 
that we provide the rCOS developer with a built-in predicate alias (pi, p2), allow- 
ing her to express that two paths are aliasing. It becomes then possible to prove that 
[ alias (a, b) h a.x' = 3] is refined by b.x := 3. The appropriate rewriting rules and 
lemmas for aliasing are included in our Maude module, and this refinement can be 
proven automatically. 

Although reasoning with aliases is directly possible in our framework, calculat- 
ing the aliasing relationship proves to be much harder. Indeed, as we never generate 
the actual graph, but only graph transformation operations, we cannot directly check 
if two paths are aliasing. Moreover, it is not trivial to statically find out if two paths 
are aliasing. For instance, an intuitive rule could say that when assigning the value 
of a path pi to a path p2, pi and p2 become aliases. However, this statement clearly 
does not hold, for instance if x represents a traditional linked list, after the assignment 
x.next := x. next. next, x.next and x. next. next, if they are different from null, are not 

10 The proof of this lemma, together with the example presented below, can be found at 
http: / /www. doc. ic.ac.uk/-~agriesma/mircos/alias. thy 
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aliasing. Hence, at this point of our development, we rely on the user to provide the 
aliasing statements, through assertions and/or preconditions, and we assume that these 
statements can be proved by another tool, such as those mentioned at the beginning of 
this section. 

9 Related Work - Discussion 

9.1 Mechanization of Refinement 

The mechanization of the refinement calculus was firstly done in ll47ll . which has been 
extended to include pointers [3| and also object-oriented programs |10 44|. In partic- 
ular, a refinement calculus has been defined for Eiffel contracts BTI . and encoded in 
PVS [40|. Although this approach addresses a similar issue than the one exposed here, 
the authors encode the calculus using a shallow embedding, that is, a class in Eiffel is 
encoded as a type in PVS, a routine in Eiffel is encoded as a function in PVS, etc. Proofs 
of refinement are then done over PVS programs rather than PVS terms, and so require 
the understanding of the underlying semantics of PVS. We use here a deep embedding, 
following ]47l . and the proofs of refinement are done, roughly speaking, over the ab- 
stract syntax tree of the original program, and so only require to know how to write a 
proof in Isabelle/Isar. The Program Refinement Tool |9| provides a deep embedding of 
a refinement calculus, and even if it does not support OO programs natively, it could 
be extended with an existing formalization which does fl46ll . However, rCOS also pro- 
vides a semantics for components, and even if we do not address in this paper the issue 
of verification of component protocols, this work is part of a larger framework where 
other verification techniques exist [45 1. In other words, the work presented here is not 
a standalone tool, but adds up to a collection of tools that helps a developer to specify, 
implement and verify an application. 

9.2 Certified Model Transformations 

The next step is therefore to express the refinement of models rather of simple state- 
ments, in particular for model transformations, which is an on-going work in the rCOS 
tool [45 1 . The principal challenge in this work is for the tool to handle several models 
at the same time: before, during and after refinement. For instance, in the example we 
have presented, we assume that the method m is already present in the class A. However, 
in practice, the software engineer might want to create the setter and change the code 
at the same time. In this case, creating the setter is a correct refinement, but in order to 
prove it, we need to also encode the structure of the whole model in Isabelle, in order 
to express that a whole model refines another one, and then define the model transfor- 
mations in Isabelle. A related approach using the Coq theorem prover has been recently 
proposed [8 1, where the Class to Relational model transformation has been certified. 

9.3 Memory Model 

Different memory models for object-oriented programs have been encoded in theorem 
provers 1121 141281 . However, the memory in these approaches is either modeled as a 
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function from addresses or pointers to values or using records to represent objects. 
Although such a modeling is very expressive, and has been shown to be adapted to 
automated demonstration, we propose here a representation of the memory by a directed 
and labeled graph, that might be more visual than a representation by a function or set 
of records. The graph structure helps in the formulation of properties and carrying out 
interactive proofs. 

9.4 Automation of Refinement 

A range of tools are developed for supporting automatic refinement. Inspired by Di- 
jkstra's weakest precondition calculus, they usually generate proof obligations corre- 
sponding to refinement requirement and then discharge them by automated reasoning 
via theorem proving. Most of them support both algorithm refinement (refining a pro- 
gram fragment or an entire method into an implementation, as we focus on in this 
paper), and data refinement (refining abstract data in specification to concrete data in 
implementation). 

Robin 1 1 1 is an open toolset which integrates construction and verification of Event- 
B Models. The system behavior in Event-B is modeled by action systems, i.e. a collec- 
tion of variables and guarded actions. Abstract specification of a model is constructed 
and then refined, following an incremental approach, however object-oriented programs 
are not directly supported. 

ProofPower Z ||25l is a tool interfaced with the YSE Zeta tool, which supports re- 
finement from Z specification to Ada programs. The tool produces verification condi- 
tions for each refinement step for input into a theorem prover, and produces Ada code by 
applying the refinement steps. However, ProofPower and YSE are using different lan- 
guages, making the communication sometimes difficult. Also, the un-readable output of 
proof in ProofPower provides little guideline for locating failures in source programs. 
Based on ProofPower Z, the authors of [22 48 1 develop the automatic refinement of 
Circus, which is a refinement language combining Z and CSP for describing state-rich 
reactive systems. 

Perfect Developer lTT7l is a software tool for developing formal specifications and 
refining them into executable code. Compared to existing refinement tools before, it 
handles object-oriented features such as inheritance, recursive call, polymorphism, dy- 
namic binding, in conformance with behavioral sub-typing principle. However, it does 
not support stepwise refinement, and requires a continuous strengthening of the code 
annotations, making the refinement less scalable. 

Leino and Yessenov [ 33 ] develop a refinement system for object-oriented programs 
and where the verification engine is based on the SMT solver Z3. It supports auto- 
mated stepwise refinement and all the intermediate steps are saved using syntax of code 
skeletons during the whole refinement process. This makes the location of failures in 
the source specification and code realizable. Moreover, it handles aliasing between data 
representations based on the permission mechanism in Chalice [32 1. 

An important strength of our work compared with these different approaches, in 
addition to the integration within the rCOS tool, a complete platform for software en- 
gineering, is the generation of a proof witness, i.e. we are not only answering if the 
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refinement is correct or not, but also providing the reason why. Hence, we can easily 
reuse previously proved lemmas, making our approach more scalable. 

9.5 Proof Generation 

Our approach for proof generation was loosely inspired by the work realized with the 
automated demonstrator Zenon [6|. Indeed, Zenon can prove first order logical formu- 
lae using the tableau method, and generate the proof in Coq. It was originally developed 
for the Focalize [23 1 environment, which provides an expressive programming language 
where properties of a program can be proved in Coq, potentially using Zenon to gen- 
erate some of the Coq proofs. An interesting feature is the definition of a simple and 
intuitive proof language following Lamport's guidelines QUI , which allows the user to 
break down a complex proof into small proofs, until a point where Zenon can prove 
automatically the statement. Such an integration is quite user-friendly, and therefore we 
aim at achieving a similar result. 

In this context, the recent integration of Zenon with Isabelle and TLA+ ifTTl can 
probably be useful. We can also try to integrate our Maude module as an automatic 
theorem prover using the Sledgehammer in Isabelle [37). 

10 Conclusion 

This paper presents, for any two programs defined within the rCOS tool, the generation 
of an Isabelle lemma stating that one program refines the other, as originally introduced 
in |[36), and extends this approach by describing a Maude module that searches for a 
sequence of refinement steps, each step being implemented as a rewriting rule. If the 
Maude module can automatically find a sequence of rules, then it generates the Isabelle 
proof of the previous lemma, otherwise the lemma still needs to be manually proven. 

The strengths of this approach are fourfold. Firstly, the generation process is inte- 
grated within the rCOS tool, and when the refinement can be automatically proven by 
Maude, then the process is transparent for the user. Secondly, the user has still the pos- 
sibility to manually prove some lemmas, when Maude cannot automatically prove the 
refinement. Thirdly, new rules can be added to the process, simply by adding the new 
lemma in the Isabelle library and the new rewriting rule in the Maude file, without any 
need to modify existing code. Finally, it generates the witness of the proof, instead of 
only returning yes or no. It follows that any proven refinement can be stored, and re- 
used later, to prove more complex refinements. For instance, if we prove that the design 
of a method foo is refined by the design of a method bar, then we can re-use this proof 
of refinement in order to prove that a call to foo is refined by a call to bar. 

This work mostly focuses on defining the framework where the different entities, 
i.e. the rCOS tool, Isabelle and Maude, can communicate together, in order to have a 
complete chain from the user of the rCOS tool, who is potentially an expert in software 
engineering rather than an expert in theorem-proving, to the proof of refinement in 
Isabelle. Hence, we have mostly considered simple examples, although rich enough to 
validate our approach, but clearly lacking the complexity of real-world programs. 
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As said in the Introduction, we build upon the previous encodings of the refinement 
calculus [47 29 20 1, and as such, we do not present here complex programs, since the 
scalability problem is identical, and we prefer to focus here on the architecture of the 
framework. However, we believe that we have paved the way towards the certification 
of more complex programs, as we can leverage the incremental aspect of the refine- 
ment calculus. Indeed, a large, complex refinement chain, as it could be expected from 
a complex program, can always be decomposed as a sequence of simpler chains of re- 
finement steps. Although some steps will probably always require a human interaction, 
such as the definition of a loop-invariant, some of tedious and repetitive steps can be 
automatically discharged. 

A limitation of this approach is that, at this current stage, the Isabelle level depends 
on assumptions made at the rCOS level, in particular for the predicate isGoodPath and 
for the aliasing problem. Clearly, external tools to reason about the program structure 
to detect aliasing and cycle properties need to be integrated in our approach. In general, 
an interesting and challenging aspect of this work was to manage the fact that the pro- 
grams we consider in Isabelle are generated from rCOS, and therefore comes with some 
implicit assumptions, such as well-formedness and type safety. However, we have no 
way to prove these properties in Isabelle, and we must limit ourselves to define and use 
well-formedness predicates. For instance, one of our previous encodings was inconsis- 
tent due to the presence of axioms that were false for infinite graphs. Although it was 
in practice impossible to generate an infinite graph from a correct rCOS program, we 
nevertheless had to revise the encoding in order to remove these axioms. 

As future work, following |20 29 1, more designs can be implemented in the transla- 
tion process, such as recursive method calls. Although rCOS supports dynamic binding, 
our encoding does not currently support it, but it could be done by adding a component 
to graph implementation to record actual types of objects, thus we can fix the method 
body actually called in the dynamic execution. 

Finally, the Maude module can be optimized, in order to avoid generating proof- 
obligations that are clearly impossible, or in general to generate less proof-obligations. 
The use of Maude meta rules for rewrite strategies seems a suitable way to tackle this 
problem. 
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